1. Technical Field of the Invention
The present invention generally relates to autonomic software systems. More specifically, the present invention is directed to an autonomic software system and method enabled to normalize a profile obtained from an executing application to account for actions applied by the autonomic system to the executing application after the profile is collected for improving the subsequent behavior of the application.
2. Description of the Prior Art
In an autonomic software system, decisions to “improve” an application are made online, i.e., as the application is executing. Specifically, the autonomic software system utilizes past application behavior during current application execution to predict future behavior of the application. Utilizing the predicted future behavior of the application, the autonomic software system may apply one or more actions (hereinafter “actions” will be used for simplicity) to the application to improve its future behavior. However, the autonomic software system is time sensitive with the following conflicting constraints: 1) deciding what actions to perform and performing those actions take clock cycles away from the execution of the application (the actions are performed while the application is executing); and 2) the longer the application executes before the actions are applied, the longer the application remains without the benefit of improvement.
Typically, the autonomic software system utilizes profiling to determine the behavior of the application, subsequently utilizes profiling information to predict the future behavior of the application, and applies actions to improve the execution of the application. The actions that the autonomic software system considers applying to the application generally determine what profiling information the autonomic software system particularly needs to obtain. For example, profiling the number of times that a method is called by the application may be used by the autonomic software system to decide whether the method should be inlined, i.e., replacing the call to the method in the body of the application with the actual statements of the method, thereby eliminating the call to that method and improving the application. As an additional example, profiling the time spent in a method of the application may be used by the autonomic software system to determine whether the method should be optimized. As a final example, profiling the communication between distributed objects may be used by the autonomic software system to determine which distributed objects should migrate between machines, thereby localizing often-invoked distributed objects to the machines from which they are invoked.
As abovementioned, the autonomic software system can change the application's runtime characteristics through the actions that the autonomic software system applies to the application on the basis of profiling information (profile) obtained from the executing application. The applied actions may cause a change in the subsequent profiling information collected for the executing application. In this situation, regions of the code of the application changed by the application of the actions will take more or less time to execute and will appear more or less frequently in the subsequent time-based profiling information. However, the profiling information obtained from the executing application does not account for the actions applied by the autonomic system to the executing application after the profile is collected. Therefore, it is desirable to normalize a profile with respect to the actions applied by a autonomic system so that the effects of the applied actions are incorporated into the normalized profile to thereby allow the autonomic software system to make better decisions when either the normalized profile is compared to subsequent time-based profiles of the application's behavior after the actions have been applied or to determine the next best action to choose given a normalized profile. In contrast, if the profile is not normalized with respect to the actions applied by an autonomic software system, then the comparison of the profile with subsequent profiles between which actions have been applied may result in the autonomic software system making faulty decisions, which is not desirable. It is note be noted that other profiling techniques alternative to the time-based profiling are known and are applicable herein.
For example, subsequent profiles may be compared to detect changes in the application's behavior. Changes in behavior of the executing application that are inherent to the application are known as phase shifts. The design and structure of the application may be conceptualized as a series of phases, where the computation of the application proceeds from one phase to the other. For the autonomic software system, the detection of phase shifts as the application executes is important because the phase shifts may indicate different resource requirements. Unfortunately, if a profile is not normalized with respect to the actions applied by the autonomic software system to the executing application, the autonomic software system cannot determine if a change in the application's behavior is due to an inherent application behavior change or a change induced by the actions. Conventionally, a phase shift may be detected by comparing behavior of the executing application in several given time intervals during which a set of runtime events execute. If the behavior of each time interval differs by some significant amount then a phase shift may have occurred or be occurring. Otherwise, if the behavior does not differ substantially, the application may be executing in a steady state. However, where the behavior of the application is modified on the fly (i.e., online) as described above, it is more problematic for the autonomic software system to detect a phase shift because the application's behavior between the several time intervals may change because of the modifications made by autonomic software system and not due to a phase shift from one phase to another.
FIG. 1 represents an illustration of a prior art autonomic system 100 that depicts the foregoing shortcomings of the prior art autonomic system. More specifically, in the prior art autonomic software system 100, an application is executed in a run time environment 102 via a profiling agent 104. The profiling agent 104 profiles the executing application 106 to generate a profile 110. The profile is transmitted to a prior art controller 114 and phase shift detector 124. The controller 114 controls the timing of when the profile 110 is collected via a control signal 108. It is noted that a plurality of profiles may be collected by the profiling agent 104, as directed by the controller 114 via the control signal 108. Generally, the controller 114 comprises a behavior adjustor 116 that adjusts the behavior of the executing application 106 by applying one or more actions 112 to the executing application. It is noted that the behavior adjustor 116 may apply no actions to the executing application as will be discussed below. The behavior adjustor 116 comprises an analyzer 118, selector 120 and applicator 122. The analyzer 118 receives and analyzes the profile 110. More specifically, the analyzer 118 receives raw data via profile 110 and transforms the raw data into a set of data that is utilizable by the controller 114. The set of data may include a sequence of basic blocks, pairs of method IDs and associated execution times, sequences of instruction cache misses, etcetera. For example, the analyzer 118 may analyze raw data, such as a plurality of method identifiers, and transform the raw data into canonical form, such as a weighted set of method identifiers where the weight of each method identifier equals the number of times the method identifier appeared in the raw data. The selector 120 receives the set of data from the analyzer 118 and selects one or more actions to be applied 112 to the executing application 106 that may help to improve the behavior of the executing application. In its determination, the selector 120 may use a cost-benefit model to determine if the cost of optimizing a method, represented by a method identifier for example, is less than the expected optimization benefit from a subsequent execution of the method, i.e., whether optimizing the method would improve the application's performance. The selector 120 then transmits the selected one or more selected actions 112 actions to the applicator 122, which applies the one or more actions 112 to the executing application 106. It is noted, that the selector may select no actions based on the cost-benefit model, in which case the applicator 122 will not apply any actions. An article by Arnold, Mathew, et al. (“Adaptive Optimization in the Jalapeno JVM.” Proceedings of the ACM Conference on Object-Oriented Programming Systems, Languages, and Applications October 2000), discloses the foregoing example. During a subsequent predetermined time interval, the profiling agent 102 may collect another profile 110 of the executing application 106 as controlled via the control signal 108. As is clear from the prior art autonomic system 100 of FIG. 1, the shortcoming of the autonomic system 100 is that neither the controller 114 nor the phase shift detector 124 has the benefit of utilizing the profile 110 obtained from the executing application that accounts for the one or more actions 112 applied to the executing application 106, after the profile 110 is collected from the executing application 106, but before the subsequent profile is collected from the executing application 106.
Therefore there is a need in the art for providing an autonomic software system and method enabled to normalize or adjust a profile obtained from an executing application to account for one or more actions applied by the autonomic software system to the executing application after the profile is collected to improve the subsequent behavior of the executing application.